home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / program / amos / amoslist.lzh / AMOSLIST / 000094_amos-request@svcs1.digex.net_Tue Sep 5 05:29:41 1995.msg < prev    next >
Internet Message Format  |  1995-10-02  |  4KB
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id FAA04614;  for <mcox@access.digex.net> ; Tue, 5 Sep 1995 05:29:40 -0400
  2. Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id CAA09786 for amos-out; Tue, 5 Sep 1995 02:35:21 -0400
  3. Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id CAA09783 for <amos-list@svcs1.digex.net>; Tue, 5 Sep 1995 02:35:20 -0400
  4. Received: from ds1.acs.ucalgary.ca (root@ds1.acs.ucalgary.ca [136.159.34.101]) by mail1.access.digex.net (8.6.12/8.6.12) with SMTP id CAA28035;  for <amos-list@access.digex.net> ; Tue, 5 Sep 1995 02:35:18 -0400
  5. Received: by acs3.acs.ucalgary.ca (AIX 4.1/UCB 5.64/4.03)
  6.           id AA38504; Tue, 5 Sep 1995 00:36:12 -0600
  7. Message-Id: <9509050636.AA38504@acs3.acs.ucalgary.ca>
  8. Subject: Re: sound compression
  9. To: chris@sixpack.pfalz.org (Chris Hodges)
  10. Date: Tue, 5 Sep 95 0:36:11 MDT
  11. From: "Robert Andrew Currie" <racurrie@acs.ucalgary.ca>
  12. Cc: amos-list@access.digex.net
  13. In-Reply-To: <wS3EfMD261aez2@p22.sixpack.pfalz.org>; from "Chris Hodges" at Sep 4, 95 8:35 pm
  14. X-Mailer: ELM [version 2.3 PL11B]
  15. Mime-Version: 1.0
  16. Content-Type: text/plain; charset=US-ASCII
  17. Content-Transfer-Encoding: 7bit
  18. Content-Length: 2603      
  19. Status: RO
  20. X-Status: 
  21.  
  22. > 
  23. > racurrie@acs.ucalgary.ca ("Robert Andrew Currie") wrote on 02.09.1995 some
  24. > text under the subject sound compression. I can't leave this uncommentated
  25. > ;-)
  26. > 
  27. > RC> The problem I am having occurs when the Load Length and Final
  28. > RC> Size are the same(Squash was unable to compress the data). When
  29. > RC> it reaches one of these segments it plays some garbage data that
  30. > RC> sounds like an out of tune vocal ladder. The segments that got
  31. > RC> compressed work perfectly. What is happening?!?
  32. > 
  33. > I think M. Lionet has messed it up again. Probably the same decrunching
  34. > will require an at least four bytes smaller data packed to decrunch... I
  35. > could be wrong of course, but it wouldn't be surprising, if this is the
  36. > fault... so don't use the compressed data on that file, even if it has
  37. > showed that it would compress to the same size. Moreover, to increase the
  38. > crunching efficiency, I would use 8-delta encoding. AMCAF provides
  39. > commands to do such an encoding :)
  40. > 
  41. > Bye, Chris Hodges <chris@sixpack.pfalz.org>      __   __
  42. > A4000/40/5MB/400HD/CD; AMOS Extension-Coder __  ///  / / _____
  43. > GCS d H s-:++ !g p? !au a18 w++ v? C+++     \\\///  / /_/ ___/ LOGOUT
  44. > E---- N++ K- W------ -po+ t++@ !5 j-- R+ G?  \XX/   \__/ __/  FASCISM!
  45. > tv- b+ D-- B? e+(++)* u++ h! f !r n+ !y+ AMIGA RULEZ!  \/
  46. > 
  47. > Ballycumber (n.)
  48. >   One of the six half-read books lying somewhere in your bed.
  49. > (from: "The Deeper Meaning of Liff")
  50. > 
  51. >
  52.  
  53.     Actually I finally got it to work. It seems that when the
  54. Squash routine fails to compress data, it does not clean itself
  55. up. The data that was unsuccessfully squashed is garbled. I
  56. corrected for this in my conversion program by first making a
  57. duplicate of the data and then attempting to squash it. The
  58. routine now plays samples of any size up to a frequency of 15000
  59. off of a harddrive with the sample segments being compressed. The
  60. total memory usage is 10K. In total I can only get about 25%
  61. compression which is not bad for large samples but pitiful for
  62. smaller ones. What is delta-8 compression? Does AMCAF work on
  63. Creator? I have theorized that for sound data, because of it's
  64. sinusoidal nature, you might be able to get away with only
  65. storing the differences between each sample byte. The difference
  66. should be far smaller than the entire sample range -128 to 127
  67. and might be representable by only 3 or 4 bits which could
  68. theoretically save you 50%-62%. Has anyone thought of this or am
  69. I totally off base? I am assuming that each sample is represented
  70. by a single byte which seems to correspond with the play time for
  71. each sample.
  72.  
  73.             Robert Currie
  74.  
  75.